AWS ParallelCluster のサポートポリシー【2021年版】
AWS ParallelClusterのサポートポリシーが2021年6月に改定されていたので改めて確認しました。メジャーアップデートが2021年9月にありv3系の登場もありました。バージョンごとのサポート期限はどうなっているのか現状を把握します。
サポート期間まとめ
- AWS ParallelCluster 3 はマイナーリリースの日付を起点に18か月先までサポートされる
- 3.0.x は、2023年3月31日まで
- AWS ParallelCluster 2.11.x は、2022年12月31日まで
- AWS ParallelCluster 2.10.4 以前は、一律2021年12月31日まで
詳細は以下のドキュメントを確認
AWS ParallelCluster 3 に関する情報
ParallelClusterは2021年9月にメジャーアップデートがあり、バージョンは3.x.xになりました。詳細は以下のリンクをご確認ください。
- AWS ParallelCluster のメジャーアップデート v3.0.0 がリリースされました | DevelopersIO
- AWS ParallelCluster 3のご紹介 | Amazon Web Services ブログ
サポートポリシー調査
サポート期限について調べようと思ったらドキュメントに載っていました。以下のリンクを確認すれば概ね解決します。
AWS ParallelCluster support policy - AWS ParallelCluster
AWS ParallelClusterは復数バージョンのクラスター環境を同時に作成・運用できます。そのため、新規でクラスターを作成するときは最新のバージョンを利用することが望ましいです。
バージョンをあげられないパターン
場合よっては以下の状況で新しいバージョンに切り替えできない、または二の足を踏むこともあるかと思います。
- OSをガリガリにチューニングして性能出し切れる環境にしている
- ジョブスケジューラはSGEかTorqueを使い続けたい
- ユーザ向けのサービスとしてガチガチに組み込んだクラスター環境を運用している
- CUDAをはじめ特定バージョンのライブラリ、ドライバが欲しくてクラスター環境を塩漬けにしている
- CentOS8を使い続けたい
よくある質問
個人的に気になる点をまとめて紹介します。
AWS ParallelClusterのバージョンアップなんてできたっけ？
一度作成したクラスター環境（pcluster createまたは、pcluster create-clusterコマンドの生成物）のバージョンをあげることはできません。
AWS ParallelClusterのバージョンアップ = クラスター環境の再構築を意味します。
サポート期限切れたら動かなくなるの？
以前のバージョンのAMI（ParallelClusterの起動するインスタンスの大本）は無期限に提供される予定とのことです。つまり、サポート期限を超過してもヘッドノード、コンピュートノードが急に起動しなくなるというこはありません。
However, existing AMIs, cookbooks, and PyPI artifacts from previous versions will be available indefinitely.
引用元: New: Introducing AWS ParallelCluster 3 | AWS HPC Blog
LTS（Long Term Support）のバージョンはないの？
残念ながら今のところないです。
半世紀共にしてきたSGEとTorqueはもう使えないの？
AWS ParallelCluster 3 のジョブスケジューラはSlurmかawsbatchの2種類のみサポートしています。経験上、ParallelClusterではSlurmを利用することが多いです。ですので、残念ながらSlurmへの乗り換えてをご検討ください。
AWS ParallelCluster 2 から 3 へ移行は簡単？
AWS ParallelCluster 3で設定ファイルの書式が刷新されました。pcluster create -cコマンドで指定していた設定ファイルはそのまま流用できません。2から3への設定内容の移行ガイドがありますので参考にしてください。
AWS ParallelCluster 3 のブログを書いたついで検証に作成したクラスターのサンプルコンフィグを載せるので参考になれば幸いです。
クラスター再構築して環境移行って大変ではないでしょうか？
AWS ParallelCluster 2 から 2 へ、 3 から 3 へは設定ファイルの書式は同じため、あまり心配しなくても大丈夫です。ただし、2.8以前から2.11ですと2.9の大幅な機能追加の影響で修正する必要になりそうです。
AWS ParallelCluster 2 はpostinstallを利用したセットアップが主流でした。新しいParallelClusterの利用に伴い、既存ライブラリ、ドライバなどのバージョンは変わっていることが大半です。そこだけ注意して検証すればpostinstallの処理自体はスクリプトを流しているだけですので容易かと思います。ParallelCluser 2 では非推奨とされてきたカスタムAMIを利用している場合はAMIの作り直しが必要です。こちらは完全な再構築と言えるでしょう。
またチューニングするの大変なんだけど？
毎度ガリガリに追い込むとParallelClusterアップデートのたびに工数がかさみます。オンプレHPCでは限りあるリソースを最大限に活かすためチューニングが必要だったかと思います。クラウドHPCですとリソースはほぼ無限なので圧倒的なリソースの量と、より性能の優れた最新のCPU、GPUに乗り換えていく選択もできます。クラウドHPCならでは活用方法にシフトしていくのはいかがでしょうか。
性能は出し切って利用費を少しでも下げるのが目的なんだけど？
チューニングに対する工数と、ParallelClusterのアップデートを行う頻度を鑑みて、より良い選択をしていただければと思います。
コンピュートノードの費用でしたらスポットインスタンスの活用で大幅にコスト削減を狙えます。中断の起きうるスポットインスタンスを活用できる方へ最適化しく方がクラウドHPCの利用方法としては適切だと私は考えています。
画像引用: S-10_AWSInnovate_Online_Conference_2020_Spring_Points_of_building_HPC_on_AWS.pdf
おわりに
以上を踏まえ個人的なクラスター構築のベストプラクティス
- 過去のクラスター管理のためにも
pclusterコマンドはpyenvなどでバージョン管理 - 新規クラスター作成するときは最新のバージョンを選択
- とくに大幅な機能追加が入っているときは事前に検証をしっかりと
- 再構築が容易にできるようセットアップをスクリプト化または、
postinstallのフル活用- カスタムAMI化を行う場合もセットアップをスクリプト化または、しっかりと構築手順を残しておきましょう
- スポットインスタンスの活用が最大のコスト削減策
- 費用対効果が圧倒的に良い
- ジョブの中断が起きても泣かないように冪等性の確保または、またジョブ投げればいいや精神の運用
